Fix alpha start in ludicrous mode #5642

ashish-goswami · 2020-06-12T13:48:57Z

Fixes: #5601
Fixes: DGRAPH-1669

Currently we are unable to start alpha server in ludicrous mode, because of reasons explained
below.

Things we do at alpha start:

At start we insert dgraph.type, dgraph.graphql.schema and dgraph.graphql.xid predicates as
our initial schema.
We also insert dgraph.graphql type(having predicates dgraph.graphql.schema and
dgraph.graphql.xid) as initial types.
We also upsert data related to graphql schema(which results in upserts for predicates
dgraph.graphql.schema and dgraph.graphql.xid).

While inserting types we verify that predicates used in the types should either already be present
in schema or should be part of same mutation where we are trying to insert this type.

In ludicrous mode we mark any proposal done without error as soon as it is retrieved as part of commited entries, as opposed to after applying proposal (this is done in normal mode).

Events which led to alpha getting stuck:

We propose schema mutation for dgraph.type, which is marked as done immediately. This
proposal is still getting applied.
Since we marked above proposal done without error, we propose next schema mutation for
dgraph.graphql.schema, which again is marked done without error. But applying of this proposal
fails as indexing was already in progress for dgraph.type. But we never retry this schema
mutation.
Next we propose dgraph.graphql.xid, which is applied successfully(indexing is done until now
for dgraph.type).
When we insert dgraph.graphql type, verifyTypes() fails, because it never finds
dgraphq.graphql.schema predicate.

Proposed solution:
Assumption that proposal is never failed while applying, hence it should be marked as done without
error immediately, should hold only for data mutations and not schema mutations.

This PR checks if proposal is data mutation(having edges > 0), while marking it done
immediately. This leads to retrying of schema proposal if they fail once because indexing is already
in progress.

Note: We didn't observe this before commit(aef7072), because predicate dgraph.graphql.schema was getting inserted via graphql upserts(#3 of start steps). Now after
commit(aef7072) we cannot insert data for predicates starting with dgraph. prefix unless those are already present.

This change is

martinmr

Reviewed 1 of 1 files at r1.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @ashish-goswami, @manishrjain, and @vvbalaji-dgraph)

worker/draft.go, line 1161 at r1 (raw file):

						if x.WorkerConfig.LudicrousMode &&
							proposal.Mutations != nil && len(proposal.Mutations.Edges) > 0 {

I think this can be written as

if x.WorkerConfig.LudicrousMode && len(proposal.Mutations.GetEdges()) > 0

GetEdges will take care of the nil case on its own.

ashish-goswami

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @manishrjain, @martinmr, and @vvbalaji-dgraph)

worker/draft.go, line 1161 at r1 (raw file):

Previously, martinmr (Martin Martinez Rivera) wrote…

						if x.WorkerConfig.LudicrousMode &&
							proposal.Mutations != nil && len(proposal.Mutations.Edges) > 0 {
I think this can be written as

if x.WorkerConfig.LudicrousMode && len(proposal.Mutations.GetEdges()) > 0

GetEdges will take care of the nil case on its own.

Done.

martinmr

Reviewed 1 of 1 files at r2.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @manishrjain and @vvbalaji-dgraph)

vvbalaji-dgraph · 2020-06-15T15:14:46Z

worker/draft.go

@@ -1157,8 +1157,9 @@ func (n *node) Run() {
 						if span := otrace.FromContext(pctx.Ctx); span != nil {
 							span.Annotate(nil, "Proposal found in CommittedEntries")
 						}
-						if x.WorkerConfig.LudicrousMode {
-							// Assuming that there will be no error while proposing.
+						if x.WorkerConfig.LudicrousMode && len(proposal.Mutations.GetEdges()) > 0 {


Skipping ludicrous mode for schema mutations seems to be the right approach. If 'Getedges' is the right mechanism for identifying schema changes then it would be good to have a comment to describe our intent here.

parasssh

Good catch! LGTM

Fixes: #5601 Fixes: DGRAPH-1669 Currently we are unable to start alpha server in ludicrous mode, because of reasons explained below. Things we do at alpha start: At start we insert dgraph.type, dgraph.graphql.schema and dgraph.graphql.xid predicates as our initial schema. We also insert dgraph.graphql type(having predicates dgraph.graphql.schema and dgraph.graphql.xid) as initial types. We also upsert data related to graphql schema(which results in upserts for predicates dgraph.graphql.schema and dgraph.graphql.xid). While inserting types we verify that predicates used in the types should either already be present in schema or should be part of same mutation where we are trying to insert this type. In ludicrous mode we mark any proposal done without error as soon as it is retrieved as part of commited entries, as opposed to after applying proposal (this is done in normal mode). Events which led to alpha getting stuck: We propose schema mutation for dgraph.type, which is marked as done immediately. This proposal is still getting applied. Since we marked above proposal done without error, we propose next schema mutation for dgraph.graphql.schema, which again is marked done without error. But applying of this proposal fails as indexing was already in progress for dgraph.type. But we never retry this schema mutation. Next we propose dgraph.graphql.xid, which is applied successfully(indexing is done until now for dgraph.type). When we insert dgraph.graphql type, verifyTypes() fails, because it never finds dgraphq.graphql.schema predicate. Proposed solution: Assumption that proposal is never failed while applying, hence it should be marked as done without error immediately, should hold only for data mutations and not schema mutations. This PR checks if proposal is data mutation(having edges > 0), while marking it done immediately. This leads to retrying of schema proposal if they fail once because indexing is already in progress. Note: We didn't observe this before commit(aef7072), because predicate dgraph.graphql.schema was getting inserted via graphql upserts(#3 of start steps). Now after commit(aef7072) we cannot insert data for predicates starting with dgraph. prefix unless those are already present. (cherry picked from commit d3c16be)

Fixes: #5601 Fixes: DGRAPH-1669 Currently we are unable to start alpha server in ludicrous mode, because of reasons explained below. Things we do at alpha start: At start we insert dgraph.type, dgraph.graphql.schema and dgraph.graphql.xid predicates as our initial schema. We also insert dgraph.graphql type(having predicates dgraph.graphql.schema and dgraph.graphql.xid) as initial types. We also upsert data related to graphql schema(which results in upserts for predicates dgraph.graphql.schema and dgraph.graphql.xid). While inserting types we verify that predicates used in the types should either already be present in schema or should be part of same mutation where we are trying to insert this type. In ludicrous mode we mark any proposal done without error as soon as it is retrieved as part of commited entries, as opposed to after applying proposal (this is done in normal mode). Events which led to alpha getting stuck: We propose schema mutation for dgraph.type, which is marked as done immediately. This proposal is still getting applied. Since we marked above proposal done without error, we propose next schema mutation for dgraph.graphql.schema, which again is marked done without error. But applying of this proposal fails as indexing was already in progress for dgraph.type. But we never retry this schema mutation. Next we propose dgraph.graphql.xid, which is applied successfully(indexing is done until now for dgraph.type). When we insert dgraph.graphql type, verifyTypes() fails, because it never finds dgraphq.graphql.schema predicate. Proposed solution: Assumption that proposal is never failed while applying, hence it should be marked as done without error immediately, should hold only for data mutations and not schema mutations. This PR checks if proposal is data mutation(having edges > 0), while marking it done immediately. This leads to retrying of schema proposal if they fail once because indexing is already in progress. Note: We didn't observe this before commit(aef7072), because predicate dgraph.graphql.schema was getting inserted via graphql upserts(#3 of start steps). Now after commit(aef7072) we cannot insert data for predicates starting with dgraph. prefix unless those are already present.

Fixes: dgraph-io#5601 Fixes: DGRAPH-1669 Currently we are unable to start alpha server in ludicrous mode, because of reasons explained below. Things we do at alpha start: At start we insert dgraph.type, dgraph.graphql.schema and dgraph.graphql.xid predicates as our initial schema. We also insert dgraph.graphql type(having predicates dgraph.graphql.schema and dgraph.graphql.xid) as initial types. We also upsert data related to graphql schema(which results in upserts for predicates dgraph.graphql.schema and dgraph.graphql.xid). While inserting types we verify that predicates used in the types should either already be present in schema or should be part of same mutation where we are trying to insert this type. In ludicrous mode we mark any proposal done without error as soon as it is retrieved as part of commited entries, as opposed to after applying proposal (this is done in normal mode). Events which led to alpha getting stuck: We propose schema mutation for dgraph.type, which is marked as done immediately. This proposal is still getting applied. Since we marked above proposal done without error, we propose next schema mutation for dgraph.graphql.schema, which again is marked done without error. But applying of this proposal fails as indexing was already in progress for dgraph.type. But we never retry this schema mutation. Next we propose dgraph.graphql.xid, which is applied successfully(indexing is done until now for dgraph.type). When we insert dgraph.graphql type, verifyTypes() fails, because it never finds dgraphq.graphql.schema predicate. Proposed solution: Assumption that proposal is never failed while applying, hence it should be marked as done without error immediately, should hold only for data mutations and not schema mutations. This PR checks if proposal is data mutation(having edges > 0), while marking it done immediately. This leads to retrying of schema proposal if they fail once because indexing is already in progress. Note: We didn't observe this before commit(aef7072), because predicate dgraph.graphql.schema was getting inserted via graphql upserts(dgraph-io#3 of start steps). Now after commit(aef7072) we cannot insert data for predicates starting with dgraph. prefix unless those are already present.

Mark proposal done immediately only for data mutation

eec4225

ashish-goswami requested review from manishrjain and vvbalaji-dgraph as code owners June 12, 2020 13:48

martinmr approved these changes Jun 12, 2020

View reviewed changes

Address review comments

45a2e30

ashish-goswami commented Jun 15, 2020

View reviewed changes

martinmr approved these changes Jun 15, 2020

View reviewed changes

vvbalaji-dgraph approved these changes Jun 15, 2020

View reviewed changes

parasssh approved these changes Jun 15, 2020

View reviewed changes

ashish-goswami merged commit d3c16be into master Jul 8, 2020

ashish-goswami deleted the ashish/ludi-gql branch July 8, 2020 08:37

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix alpha start in ludicrous mode #5642

Fix alpha start in ludicrous mode #5642

ashish-goswami commented Jun 12, 2020 •

edited

Loading

martinmr left a comment

ashish-goswami left a comment

martinmr left a comment

vvbalaji-dgraph Jun 15, 2020

parasssh left a comment

Fix alpha start in ludicrous mode #5642

Fix alpha start in ludicrous mode #5642

Conversation

ashish-goswami commented Jun 12, 2020 • edited Loading

martinmr left a comment

Choose a reason for hiding this comment

ashish-goswami left a comment

Choose a reason for hiding this comment

martinmr left a comment

Choose a reason for hiding this comment

vvbalaji-dgraph Jun 15, 2020

Choose a reason for hiding this comment

parasssh left a comment

Choose a reason for hiding this comment

ashish-goswami commented Jun 12, 2020 •

edited

Loading